feat(routines): return the day's description from get_workout_for_date - #21
Merged
rolandgeider merged 3 commits intoSep 3, 2026
Merged
Conversation
A routine's per-day description is where the notes live that the numbers alone do not carry: rep ranges, which machine substitutes for which, form cues. get_workout_for_date is documented as "the one call that answers 'what am I doing today'", and it was returning the prescribed sets, reps and RiR while dropping the field that says on what terms. The gap is not academic. A day whose description reads "working reps = lower end of range: bench 6-8, press 8-10" prescribes a range, and a caller working only from the payload reports "6" and "8" as fixed targets. The information exists, one field away, on an object this function already resolves. Unset comes back as null, the same treatment day_name already gets, so the field is always present and never leaks a sentinel across the tool boundary.
wromansky
marked this pull request as ready for review
September 2, 2026 02:28
get_workout_for_date answers from two return paths, and the second one — outside the routine's range, or no day scheduled on that date — mirrors every key of the first so a caller never has to branch on which answer it got. day_description was added to the scheduled path only, so on a date with no day the key was absent entirely, where day_name is a safe None. A caller reading out["day_description"] got a KeyError exactly on the dates it has least reason to expect one. The existing test for that path asserted is_rest_day, planned, iteration and note, so nothing caught it; it now asserts the key as well, and fails without the fix. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
README: the branch carried the add_exercise_with_sets row from before wger-project#16, so taking its side wholesale would have dropped the note that an omitted weight_unit follows the trainee's profile. Master's row for that tool, this branch's row for get_workout_for_date. CHANGELOG: both entries stand, wger-project#16's first. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The problem
A routine's per-day
descriptionis where the notes live that the numbers alone do not carry: rep ranges, which machine substitutes for which, form cues.get_workout_for_dateis documented as "the one call that answers 'what am I doing today'", and it returned the prescribed sets, reps and RiR while dropping the field that says on what terms.The gap is not academic. A day whose description reads "working reps = lower end of range: bench 6-8, press 8-10" prescribes a range, and the stored
repetitionsvalue is its bottom. A caller working only from the payload reports "6" and "8" as fixed targets — which is what the routine's author was trying to prevent by writing the note in the first place. The information already exists, one field away, on an object this function resolves anyway.The change
One field:
day_description, alongsideday_name, from thedayobjectget_workout_for_datealready has in hand.Unsetbecomesnull, the same treatmentday_namegets, so the key is always present and no sentinel crosses the tool boundary.Docstring, README tool table and CHANGELOG updated to match.
Why here rather than in the caller
The alternative is telling every caller to make a second
get_routine_daycall to fetch the description. That is a round trip per session for a field the server has already loaded, and it only helps callers that know to ask — which is the ones that already understand the problem. Returning it from the default read path means the notes arrive with the plan they annotate, for everyone, at no extra request.Tests
Two existing tests extended rather than new ones added, since both already cover this exact boundary:
test_returns_slot_entry_ids_for_todayasserts the description reaches the caller.test_unnamed_day_still_answersnow also setsdescriptiontoUNSETand assertsNone, pinning the sentinel treatment next to theday_namecase it already guarded.Verified they bite: with the new field removed from the source, both fail (one
KeyError). Full suite 247 passed,ruff checkclean.Note
Touches
get_workout_for_date's return dict and docstring. Independent of #16, #17, #18, #19 and #20; the only shared file isCHANGELOG.md's## Unreleasedblock, which is a one-hunk conflict for whichever lands second.